home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 8 / QRZ Ham Radio Callsign Database - Volume 8.iso / pc / files / p_misc / netconf.arc / A802.TXT next >
Text File  |  1988-12-10  |  36KB  |  724 lines

  1.                     Fred R. Goldstein k1io
  2.                     25 October 1988
  3.  
  4. Preface
  5.  
  6. This is a draft description of a potential protocol for providing
  7. the Data Link Layer service to packet radio networks in the Amateur
  8. Radio Service.  This draft presumes a familiarity with the AX.25
  9. protocol adopted by the American Radio Relay League.  Actual
  10. implementation is not suggested at this time.
  11.  
  12. Intended audience:  Amateur packet radio operators.  This draft is
  13. leading towards an "ARFC".
  14.  
  15.  
  16. The A802 Metropolitan Area Network Protocol for Amateur Packet Radio
  17.  
  18. I.  Introduction
  19.  
  20. Amateur Packet Radio has been practically synonymous with the AX.25
  21. protocol since the early 1980s.  While AX.25 has allowed packet
  22. operation to become quite popular, it has not proven to be fully
  23. sufficient for the task.  Instead, it has created a minor industry
  24. in Terminal Node Controllers, which have isolated their users, and
  25. their computers, from the protocols themselves.
  26.  
  27. A totally different protocol can take the place of AX.25, especially
  28. when used with more sophisticated upper layers such as TCP/IP.  A
  29. candidate for such a protocol can be loosely based upon Local Area
  30. Networks which operate over shared cable; A802 takes such an
  31. approach.
  32.  
  33. I.1. AX.25 is itself a misnomer
  34.  
  35. AX.25 takes its name from Recommendation X.25 of the CCITT, the
  36. international consultative body that makes standards for telephone
  37. networks.  X.25 itself is a definition for a standard interface into
  38. packet switched networks.  It defines, in detail, two different
  39. layers of software.  Layer 2 (or Level 2, in X.25's original
  40. terminology) is the Data Link layer, responsible for ensuring error-
  41. free transmission between adjacent entities.  Layer 3 is the Network
  42. layer (originally the Packet layer) which operates across the
  43. boundaries of the network, establishing virtual circuits
  44. (connections) between users.  (Layer 1, the Physical Link layer,
  45. simply transfers bits across a data connector, like the widely used
  46. RS-232 interface.  Modem standards fall within the bounds of Layer
  47. 1, but are not part of X.25.  Packet radio standards for Layer 1 are
  48. only partially covered within this document.)
  49.  
  50. X.25's Data Link layer uses a protocol called LAP-B (Link Access
  51. Protocol - Balanced).  This has been adapted, with much change, into
  52. AX.25.  While X.25's network layer has been implemented in some
  53. connection-oriented networks, it is not part of AX.25.  So the name
  54. AX.25 is really a misnomer; it is simply a much modified LAP-B.
  55.  
  56. Like LAP-B, AX.25 is a member of the HDLC (High Level Data Link
  57. Control) family of protocols.  HDLC frames (which is the correct
  58. term for packets at Layer 2) begin and end with a flag character,
  59. and allow data transparency by a bit insertion (stuffing) procedure. 
  60. The last two bytes of the frame are the checksum, or cyclic
  61. redundancy check (CRC).  Bit stuffing (and removal, on receive) is
  62. easily accomplished with specialized hardware, but next to
  63. impossible using standard personal computer modem interfaces.  Hence
  64. the need for a TNC with its HDLC chip.
  65.  
  66. While X.25 is widely used, it really has little in common with
  67. packet radio.  For one thing, X.25 networks run over point to point
  68. wire lines.  And LAP-B doesn't worry about addressing (there are
  69. only two stations on the wire, one at each end); lengthy address
  70. strings were added to create AX.25.
  71.  
  72.  
  73. II.  The data link, the LAN and the MAN
  74.  
  75. Packet radio operators know that their networks are not derived from
  76. X.25 wireline networks, as packet networks are often called Local
  77. Area Networks (LANs).  This is not strictly accurate, since a LAN
  78. operates only within a building or campus, but packet radio MANs
  79. (metropolitan area networks) are still a lot more like LANs than
  80. like X.25 links.  LAN protocols don't exactly follow the same
  81. layered model as X.25 or LAP-B, either:  They don't strictly map
  82. into the traditional Layer 1 and Layer 2.
  83.  
  84. The most widely used LAN standards are defined by IEEE committee
  85. 802, and include 802.3 (based on Ethernet), 802.4 (token bus) and
  86. 802.5 (token ring).  Since token-passing has not been successfully
  87. demonstrated on packet radio, 802.3 comes closest to modeling radio.
  88. Indeed, the name "Ethernet" was coined by its inventors who noted
  89. that the coaxial cable was a broadcast medium not entirely unlike
  90. radio.  Alas, it is also quite different from radio:  Not only does
  91. it run much faster, but it is virtually lossless.  
  92.  
  93. II.1 LAN layers
  94.  
  95. The lowest layer in a LAN, roughly within the physical link layer,
  96. is called the Physical Medium Dependent (PMD) layer.  This, of
  97. course, differs greately between the different types of 802 LANs. 
  98. The PMD layer is concerned with how bits are transmitted.  The next
  99. layer up is the Medium Access Control (MAC) layer; this is where the
  100. stations on the LAN address each other, and determine when they can
  101. transmit.  Finally, the Logical Link Control (LLC) layer provides
  102. the same types of services as a Data Link layer.  There are two LLCs
  103. defined in IEEE 802.2; LLC1 provides a datagram service (like UI
  104. frames), while LLC2 provides a virtual circuit service (like I
  105. frames).  LLC2 procedures (the types of frames and how they
  106. interact) are very close to LAP-B.
  107.  
  108. II.2  The A802 protocols
  109.  
  110. The LAN protocols found in IEEE 802 provide a model for packet
  111. radio.  For the sake of discussion, these are herein called "A802";
  112. the IEEE 802 protocols are merely an inspiration, but provide a
  113. model, just as X.25's Layer 2 provided a model for AX.25.
  114.  
  115. A802 starts with a different premise than AX.25.  It does not use
  116. HDLC, so there is no bit stuffing, and ordinary PC asynchronous
  117. communications hardware can be used.  It also pays a bit less
  118. attention to terseness -- LAP-B headers cram a lot into a few bytes,
  119. but lack flexibility.  
  120.  
  121. As a further note, A802 can be run in either asynchronous or
  122. synchronous mode -- a low-end implementation can be sent using a
  123. standard asynchronous modem port, and monitored without special
  124. hardware.  However, net throughput will be higher if synchronous
  125. transmission is used, and the two modes are not compatible.  Thus
  126. any given transmission channel must be either synchronous or
  127. asynchronous or some stations will not be able to contact others.
  128.  
  129. II.3  The A802 frame structure
  130.  
  131. An A802 frame takes the following format:
  132.  
  133.     Frame {
  134.                 Sync_characters         Literal "^V"s   Mandatory
  135.                 MAC_header         Structure       Mandatory
  136.         LLC_header           Structure         Mandatory
  137.         Data                 String          Optional
  138.         Frame_checksum       2 bytes         Mandatory
  139.                         }
  140.  
  141. The sync_character is not part of the A802 frame itself, but is
  142. always transmitted at least twice before every frame.  It has
  143. the literal decimal value of 22, or control-V; its purpose is to
  144. allow the receiving modem to establish synchronization.  In
  145. synchronous mode, it establishes both byte and frame
  146. synchronization; in asynchronous mode, it only establishes frame
  147. sychronization.  Note that HDLC protocols such as AX.25 can send any
  148. number of flag characters between frames; IEEE 802.3 precedes each
  149. frame with a stream of alternating 1 and 0 bits for synchronization.
  150.  
  151. The A802 "header" consists of two separate sub-layers.  The MAC
  152. sublayer provides addressing functions, while the LLC sublayer
  153. provides both connection-oriented and connectionless options. 
  154. AX.25's basic functions are still provided, including support for
  155. digipeating.
  156.  
  157. II.4  The MAC layer
  158.  
  159. The Medium Access Control layer allows stations to address frames to
  160. one another.  It is possible for a connection-oriented protocol to
  161. have a very small address field; instead of putting a full address
  162. (typically here, a call sign) in each frame, a data link control
  163. indicator (DLCI) refers to a previously-created connection.  This
  164. has been done in the pioneering VADGC (Vancouver) packet radio
  165. protocols, and is done in both LAP-D (the ISDN follow-on to LAP-B)
  166. and X.25's Network Layer, which are connection-oriented.  Like
  167. AX.25, however, A802 puts the source and destination addresses in
  168. every frame, allowing them to be handled as datagrams.  A802 also
  169. supports digipeating.
  170.  
  171. The fundamental components of a MAC header are the sender's and
  172. receiver's addresses.  For example, Ethernet (and its follow-on IEEE
  173. 802.3) have a 48-bit address, so 96 bits of the MAC header are taken
  174. up by addressing.  But digipeating makes life more complicated! 
  175. Digipeating is more precisely referred to as source routed MAC 
  176. relay:  Source routed because the path is specified by the source of
  177. the packet, and MAC relay because the frame is simply relayed by the
  178. intermediate stations without looking at layers above MAC.  (Source
  179. routing is supported in IEEE 802.5, the token ring LAN.)
  180.  
  181. The MAC header can be described as
  182.  
  183. MAC_header {
  184.         Hop_pointer                  Integer         (Mandatory)
  185.         Destination_address          Structure       (Mandatory)
  186.         Intermediate_address_1..7    Structure       (Optional)
  187.         Source_address                 Structure         (Mandatory)
  188.         Protocol_discriminator         Alpha           (Mandatory)
  189.          } 
  190.  
  191. II.4.1  Addresses
  192.  
  193. Each address field typically contains a call sign.  In a simple two-
  194. station connection, the sender of the packet puts its call sign in
  195. the Source_address field and puts the other station's call in the 
  196. Destination_address field.  Secondary station IDs can be appended to
  197. the callsigns, as can portable identifiers, as the address is not
  198. constrained to 8 bytes (unlike AX.25 Version 2.0).  
  199.  
  200. II.4.2  Source routing
  201.  
  202. Digipeating is accomodated via the Intermediate_addresses and the
  203. hop_pointer.  The hop_pointer indicates which of the addresses
  204. (destination or intermediate) the frame is being directed to.  In a
  205. two-station (no digipeater) packet, the Hop_pointer always has a
  206. value of 1.  If there is one digipeater, then it begins with a value
  207. of 2; this means that the receiver recognizes the packet as its own
  208. when its own address is in the Intermediate_address_1 position. 
  209. Likewise, if there are two digipeaters, the first digipeater
  210. increments the hop_pointer to 3 so that the second digipeater
  211. recognizes its address in the intermediate_address_2 position.  And
  212. the last digipeater sets the hop_pointer to 1, the position of the
  213. destination address.
  214.  
  215. A multicast or broadcast frame is sent with the hop_pointer set to
  216. 0.  Thus the hop_pointer can have any value from 0 to 8.  
  217.  
  218. The hop_pointer is designed to reduce the processing load on
  219. receivers; they only have to listen to see if the pointed-to address
  220. is their own, and if it is not, then the frame can be ignore. The
  221. most common value will be 1; when this occurs, receiving stations
  222. may ignore subsequent addresses.  (Conversely, when a frame has a
  223. hop_pointer value of 8, then every digipeater that hears it must
  224. wait until Intermediate_address_8 is sent.  This is, of course, a
  225. degenerate case, as it is highly unlikely that a chain of 8
  226. digipeaters will work! 
  227.  
  228. For identification purposes, the sender (as contrasted with the
  229. originator) of each transmitted frame is identified by determining
  230. the previous hop in the source routing chain. 
  231.  
  232. II.4.3 The protocol discriminator
  233.  
  234. One final field in the MAC header is the protocol discriminator. 
  235. This allows the upper layers to know what type of protocol the A802
  236. frame is carrying in its data field.  It should be noted that in the
  237. current Open Systems Interconnection Reference Model, protocol
  238. discriminators are taboo -- different protocols at the same node
  239. should be distinguished by different addresses.  But AX.25 uses a
  240. protocol discriminator, Ethernet (pre-802) uses a protocol
  241. discriminator, and most TCP/IP users have grown to expect a protocol
  242. discriminator.  So A802 has one too.  (This does not rule out using
  243. distinctive addresses, if one chooses to do so.)
  244.  
  245. The protocol discriminator is a single upper-case letter (A-Z). 
  246. Tentatively values are as follows:
  247.  
  248.               Letter        Protocol type
  249.  
  250.                 I       IP (as in TCP/IP)
  251.                 R       ARP (Address Resolution Protocol)
  252.                 X       X.25 Packet layer or OSI CONS (ISO 8208)
  253.                 O       OSI Internet Protocol (ISO 8473)
  254.                 T       Plain text 
  255.  
  256.  
  257. Other values will be assigned as required.
  258.  
  259. II.4.4.  Parsing the MAC header
  260.  
  261. Since some of the header fields are of variable length, they must be
  262. separated from one another.  There are several techniques that could
  263. be used for this.  LAP-B uses only fixed-length fields, while AX.25
  264. uses fixed-length addresses with a bit set to indicate whether or
  265. not each has already been digipeated and another set to indicate
  266. which address is the last.  Some protocols (notably those used in
  267. Open Systems Interconnection, the OSI program of the International
  268. Organization for Standardization) use a tag-length-value technique,
  269. which is very flexible but frequently takes at least 3 octets to do
  270. anything.  
  271.  
  272. A802 is a bit more like natural language -- it relies on taking each
  273. byte's values in context.  Individual fields can only have certain
  274. values, so they end when a separator character, or one which cannot
  275. be part of that field, occurs.  In A802, the MAC header is encoded
  276. using printable ASCII characters.
  277.  
  278. The first octet of the MAC header is always a numeral, in the range
  279. 0-9 (although value 9 is presently reserved).  This hop_pointer is
  280. followed by the destination_address.  This can contain the
  281. characters A-Z, 0-9, plus the hyphen "-" and slash "/".  The
  282. secondary station ID field, an AX.25 artifact whose value can be 0
  283. through 15, can further be encoded using one ASCII character
  284. representing a hexadecimal digit, in the ranges 0-9 plus a-f,
  285. immediately following the call sign.  Or a hyphen can be used,
  286. noting that K1IO-10 and K1IOa are two different addresses, though
  287. both represent the same ss_id.  (Should these be equated?  This
  288. requires further study.)  Terse format (K1IO3) is recommended.
  289.  
  290. Intermediate_address fields are optional, inserted only as required. 
  291. Each one begins with the ASCII character "v", and then encodes call
  292. sign the same way as the destination_address.
  293.  
  294. The source_address field, using the same encoding technique, is
  295. preceded by the ASCII character "<" (less than, or left-pointing
  296. angle bracket).  This character is equivalent to the Morse code
  297. "DE".  
  298.  
  299. II.4.5  Examples of MAC header addressing
  300.  
  301. A packet addressed to K1IO from 4X/WB2ZJQ1 without a digipeater:
  302.  
  303.     1K1IO<4X/WB2ZJQ1
  304.  
  305. A packet addressed to FG0/K1IO/FS7-3 (K1IO operating portable on St.
  306. Martin using an FG0 authorization and the informal suffix FS7, SSID
  307. 3) from KA9Q8 via digipeaters WB2ZJQ and NP4XYZ would be initiated:
  308.  
  309.      2FG0/K1IO/FS7-3vWB2ZJQvNP4XYZ<KA9Q8
  310.  
  311.  This would be picked up by WB2ZJQ would would transmit:
  312.  
  313.     3FG0/K1IO/FS7-3vWB2ZJQvNP4XYZ<KA9Q8
  314.  
  315. and it would finally be transmitted to FG0/K1IO/FS7-3 from NP4XYZ:
  316.  
  317.     1FG0/K1IO/FS7-3vWB2ZJQvNP4XYZ<KA9Q8
  318.  
  319. It is possible to identify the sender (not originator, but the
  320. digipeater) of each packet, by following the process backwards!
  321. This is not particulaly human-friendly, but unambiguous to a
  322. computer. Note that the protocol discriminator is not shown above;
  323. it is the byte immediately preceding the LLC separator ":" (colon).
  324.  
  325. II.5  The Logical Link Control header
  326.  
  327. Logical Link Control provides the rest of the protocol's functions. 
  328. A connection-oriented LLC (like IEEE 802's LLC2) provides an error-
  329. corrected, sequenced stream of frames -- a virtual circuit.  AX.25's
  330. virtual circuit mode does the same thing; this is the usual way X.25
  331. networks use LAP-B.  A connectionless LLC (like IEEE 802's LLC1)
  332. does not try to make up for losses in the physical medium, but it is
  333. simpler and often adequate.  This corresponds to UI frames in AX.25.
  334.  
  335. Two LLCs are defined in A802.  LLC-U is essentially similar to LLC1,
  336. providing an unsequenced datagram delivery service.  LLC-C provides
  337. a connection-oriented (sequenced) service similar to that provided
  338. by LLC2.  It does not, however, follow LLC2's specific procedures.
  339.  
  340. The A802 LLC header also helps provide the frame integrity.  It
  341. includes a frame length field and a header checksum.  Since A802
  342. does not follow the HDLC flag-delimiting technique or reserve any
  343. characters for "end of packet", it needs a way to indicate the end
  344. of a frame:  The frame length field indicates how many bytes of data
  345. are in the frame, so the receiver simply counts bytes to determine
  346. the end of the frame.  The header checksum decreases the chance
  347. that an error in the address or frame length causes the rest of the
  348. frame to be incorrectly framed, with the chance that an incorrect
  349. frame checksum is accepted. 
  350.  
  351. The LLC header takes this structure:
  352.  
  353.    LLC_header {
  354.            Separator         Lit.  ":"      Mandatory
  355.            Control              Alphabetic     Mandatory
  356.            Receive_sequence  Alphabetic     Optional
  357.            Transmit_sequence Alphabetic     Optional
  358.            Length              Integer     Mandatory
  359.            Header_Checksum   Integer        Mandatory
  360.              }
  361.  
  362. Note that the Control, Receive_sequence and Transmit_sequence fields
  363. will be described in Section III, below.  All header fields up to
  364. and including Transmit_sequence are encoded in printable ASCII
  365. character; the remaining portion of the LLC header, and the rest of
  366. the frame, may have any arbitrary value. 
  367.  
  368. II.5.1  Length
  369.  
  370. A802 is a byte-count protocol.  The length field is not encoded in
  371. ASCII; it is a two-byte integer, with the high order byte followed
  372. by the low order byte.  This allows large frames, though many or
  373. most frames will have a zero value in the high-order byte.  The
  374. length field counts the number of bytes in the data field, following
  375. (not including) the header checksum.
  376.  
  377. Some frames do not contain a data field.  In such a case the length
  378. field remains, with a value of 0.
  379.  
  380. II.5.2  Header Checksum
  381.  
  382. The header checksum field is only intended to detect some number of
  383. header errors.  It is a simple, one-byte value computed by adding up
  384. the binary value of every previous byte in the header plus the total
  385. number of bytes in the header (not including the checksum).  If the
  386. checksum does not match when computed by the receiver, then the
  387. frame is discarded.  The receiver also does not have confidence in
  388. the length field, and may lose frame synchronization (see below).
  389.  
  390. II.5.3  The data field
  391.  
  392. The whole point of this protocol is to exchange data; the header
  393. simply facilitates it.  The data field in A802 begins six bytes
  394. after the separator (":") in I frames, four bytes after the
  395. separator in U frames, and five bytes after the separator in S, G
  396. and R frames.  The maximum length of the data field is subject to
  397. negotiations by the two parties, and should be restrained in order
  398. not to "hog" a channel, but in a high-speed network can be as long
  399. as 8191 bytes.  (This value is for further study.)  On a 1200 bps
  400. half-duplex channel, however, a maximum of 256 bytes is recommended.
  401.  
  402. There are no constraints on the contents of the data field, except
  403. that it must be an integral number of octets long.  Segmentation of
  404. packets to accomodate different maximum data field lengths is for
  405. further study.
  406.  
  407. II.5.4  The frame checksum
  408.  
  409. At the end of every frame, following the data field (and not
  410. included within the length field) is the frame checksum.  This is
  411. computed on the entire frame, beginning with the hop pointer and
  412. ending with the last byte before the frame checksum.
  413.  
  414. The frame checksum uses the 16-bit CRC-CCITT cyclic redundancy
  415. checksum, identical with the one in AX.25.  While computationally
  416. rather intensive, it will detect essentially all errors of fewer
  417. than sixteen bits and most longer errors.  (Since A802 is intended
  418. for use in the absence of dedicated "TNC" hardware, which would
  419. normally implement CRC in hardware, use of a different checksum is
  420. for further study.)
  421.  
  422.  
  423. III.  LLC procedures
  424.  
  425. III.1  LLC-U operation:  Connectionless
  426.  
  427. The A802 connectionless mode of operation has a very simple LLC
  428. sublayer.  The Control field has a value of "U", corresponding to
  429. Unnumbered Information (UI) frames in AX.25.  All such frames stand
  430. alone.  They do not have a receive_sequence or transmit_sequence.
  431.  
  432. Thus the LLC-U header begins with the separator ":", followed
  433. immediately by the Length field and Checksum.  If the frame checksum
  434. (as well as the header checksum) is valid, then the data is passed
  435. to the next layer up.  If the checksum is invalid, then the data is
  436. not passed.  
  437.  
  438. III.2  LLC-C operation:  Connection oriented
  439.  
  440. A connection-oriented Logical Link Control provides sequenced,
  441. error-corrected packets.  This isn't so simple:  If a packet isn't
  442. acknowledged, it must be retransmitted by the sender.  And since it
  443. might take some time for this to occur, the sender may wish to send
  444. more than one packet at a time.  This is called a window, and is a
  445. feature of both AX.25, LAP-B and many higher layer protocols.
  446.  
  447. A802's LLC-C defines three phases of data communications: 
  448. Connection establishment, data exchange, and connection release. 
  449. Connection establishment uses a three-way handshake (unlike AX.25's
  450. two-way handshake).  Connection release uses a two-way handshake
  451. (more like AX.25).  Each step can be described as a change in the
  452. connection state.  These stages are initiated by values in the
  453. Control field.
  454.  
  455. III.2.1  Connection establishment
  456.  
  457. A802's connection establishment begins with the connection in a null
  458. state.  The station which initiates the connection sends a frame
  459. with the Control field set to "A" ("ask for connection").  That
  460. station moves into the connection initiated state.  The recipient
  461. station, if it chooses to accept the request, immediately responds
  462. with the Control field set to "B" ("begin to connect").  Neither A
  463. nor B frames may contain data.  (A802 does not support "fast
  464. connect".  You want fast, you use U frames!)  The recipient, who
  465. sent the "B", is now in the connection pending state.
  466.  
  467. If the receiver does not want to accept a connection request, then
  468. it responds not with a "B" but with a No Contact frame (Control
  469. value of "N").  The receiver stays in the null state.
  470.  
  471. After receiving a "B" frame, the initiator sends a Connect frame
  472. (Control value of "C").  This step allows the recipient of the
  473. connect request to know that its "B" frame was received.  Upon
  474. sending the C frame, the initiator moves into connected state; the
  475. receiver moves into connected state when it receives the C frame.  
  476.  
  477. As you can see, connection establishment is as simple as A-B-C!  But
  478. of course, there are complications, mainly a number of necessary
  479. timers.  When the initiator moves into the connection initiated
  480. state, it starts Timer A to await a response.  If Timer A expires
  481. without any response, then the connection is assumed to have failed. 
  482. It may re-initiate with another A frame.
  483.  
  484. Once the recipient sends a B frame, it starts Timer B.  If it does
  485. not receive a C frame before Timer B expires, then it retransmits
  486. the B frame once and restarts Timer B.  If no C frame is received,
  487. then it assumes that the connection is lost and returns to the null
  488. state.  If the C frame was lost, the originator will not know it
  489. until another B frame is received.  It may have begun transmitting I
  490. frames in the meantime, but I frames must be acknowledged, and the
  491. receipt of a second B frame implies that the I frames have been
  492. rejected.  Similarly, I frames received before a C frame are
  493. discarded by the receiver as being out of sequence.
  494.  
  495. III.2.2  Data exchange
  496.  
  497. Once a connected state is achieved, data exchange may begin.  A802's
  498. connected mode makes use of sliding windows, not unlike AX.25.  But
  499. in keeping with A802's alphabetic nature, it adopts a modulus of 26;
  500. letters are used to indicate the send and receive variables.
  501.  
  502. The receive_sequence is encoded using lower-case ASCII letters; the
  503. transmit_sequence is encoded in upper case.  During information
  504. exchange, the receive_sequence is transmitted in I, S and G frames;
  505. it has the downcased version of the next letter (a-z, wrapping z to
  506. a) after the last correctly-received frame's transmit_sequence.  The
  507. transmit sequence (A-Z, wrapped) identifies each unique sequenced
  508. frame.
  509.  
  510. Thus the first station to transmit information after connection
  511. establishment sends the I frame with sequence variables "IaA",
  512. inviting the other side to send its own frame A.  If side X has
  513. received five frames frpm side Y and not transmitted any, then sends
  514. one frame, it sends "IeA".  If X has a second frame to transmit
  515. right away, that frame is sequenced "IeB".  Then, if Y sends its
  516. sixth frame, it sends IcF, which acknowledges X's frame B.
  517.  
  518. In theory this allows up to (modulus - 1) 25 frames to be
  519. outstanding at once.  This window size value k is typically much
  520. lower; in some half-duplex packet radio environments, it may need to
  521. be as low as 1, whence every frame must be acknowledged before
  522. another can be sent.  Windows belong to the transmitting side only
  523. and need not be symmetrical; a station simply doesn't transmit more
  524. than k frames ahead of the last acknowledged frame.
  525.  
  526. Every I frame must be acknowledged within the duration of the
  527. sender's timer I.  If there is a relatively constant flow of data in
  528. both directions, then each side's I frames acknowledge the other
  529. side's.  If, however, the recipient does not have data to send, then
  530. it still needs to acknowledge the received data before the sender's
  531. timer I expires.  This is accomplished by sending a G (Go) frame
  532. with the appropriate receive sequence_value (the transmit_sequence
  533. value one after that of the last received I frame).  Timer G
  534. determines how long the recipient waits before sending this G frame.
  535.  
  536. If a frame is not acknowledged within timer I, then the station
  537. retransmits the frame.  If a station retransmits the same frame 
  538. r times without being acknowledged, then it assumes that the
  539. connection has been lost.  It then transmits a D frame.
  540.  
  541. III.2.3  Flow control
  542.  
  543. Sometimes one side of a connection is incapable of handling any
  544. additional I frames.  This may occur because of congestion further
  545. down the network, or because its receiver has filled (or anticipates
  546. imminently running out of) its buffers.  When a station expects to
  547. be unable to handle additional traffic, it sends an S (Stop) frame. 
  548. This contains a receive sequence value but not a transmit sequence. 
  549. The sender of the S frame is now in a stopped state.  Any I frame
  550. data received at this time is expected be discarded.  (U frames may
  551. be accepted or rejected at the recipient's option.)  Upon receipt of
  552. an S frame, the sender enters halted state.  
  553.  
  554. A station in halted state may not send further I frames, but may
  555. itself acknowledge receipt of I frames via S frames.  A station in
  556. stopped state may, however, send I frames.
  557.  
  558. Once the station is again able to receive traffic, it sends a G
  559. frame, moving from stopped to connected state.  Its receive_sequence
  560. value should be the next one after that of the last I frame and
  561. match the one in the S frame which it cancels; however, at the
  562. receiver, value of the G frame takes precedence in case of mismatch. 
  563. (This allows the receiver to accept additional I frames after
  564. sending an S frame, at its discression.  S and G frames correspond
  565. loosely to RNR and RR frames in AX.25 and LAP-B.)
  566.  
  567. III.2.4  Out of sequence packets
  568.  
  569. If a valid frame is received whose transmit sequence is not exactly
  570. one more (modulo 26 from the A-Z sequence) than the last correctly
  571. received frame, then it is out of sequence.  A802 is intended to
  572. operate only over simple point to point links, or over static
  573. digipeater chains, so sequence should always be preserved.  Thus out
  574. of order packets imply that intervening packets have been lost.  The
  575. recipient of an out of sequence frame should send an R frame with
  576. the receive_sequence value one greater than the correctly received
  577. frame's transmit_sequence.
  578.  
  579. III.2.5  Connection release
  580.  
  581. When either side of a connection wishes to release the connection,
  582. it sends a D (Disconnect request) frame.  This contains a
  583. receive_sequence value one ahead of the last correctly received
  584. frame's transmit_sequence. It goes into the disconnect pending
  585. state.  The recipient of a D frame immediately acknowledges it with
  586. an E (End) frame, which has no associated sequence variables.  At
  587. this point both stations go into the disconnected mode.
  588.  
  589. If the sender of the D frame does not receive an E frame within the
  590. time specified by timer A, then it should retransmit the D frame up
  591. to r times.
  592.  
  593. III.3  Header checksum errors
  594.  
  595. For every received frame, the header checksum should be computed and
  596. compared to the received value.  If it is incorrect, then the frame
  597. is simply discarded.
  598.  
  599. Since the number of bytes in the frame is part of the header
  600. checksum, the receiver must resynchronize.  This is accomplished by
  601. waiting for two successive bytes with the decimal value of 22
  602. (control-V) followed immediately by an ASCII representation of a
  603. numeric value, which could represent the first byte of a frame. 
  604. This may or may not mark the beginning of a new frame.  The receiver
  605. must then see if the potential new frame has a valid header
  606. checksum.  Other heuristic means of determining frame breaks are for
  607. further study.  Frame synchronization can typically be re-attained
  608. from the beginning of a new transmission, as noted from the Data
  609. Carrier Detect signal or squelch signal.
  610.  
  611. III.4  Frame checksum errors
  612.  
  613. If the frame checksum of any frame but an I frame is correct but the
  614. frame checksum is incorrect, then the receiver discards the frame.
  615.  
  616. If the header checksum of an I frame is correct but the frame
  617. checksum is incorrect, then the receiver can have a fair degree of
  618. confidence that the frame in question comes from the sender
  619. identified in the MAC header, even if the data itself is valid.  If
  620. the recipient of this corrupted data field has data to transmit,
  621. then it sends an I frame with the receive sequence value of the next
  622. anticipated frame following the last received valid frame.  For
  623. example, if frame M was received correctly and a corrupt frame N was
  624. then received, the receiver's next outgoing I frame should have a
  625. receive sequence of "n".  The transmitter then resumes from its
  626. frame N.
  627.  
  628. If the recipient of the corrupted data does not have data to
  629. transmit, it should, without further waiting, send an R (Reject)
  630. frame with its receive_sequence value one after the last valid
  631. received frame's transmit_sequence value.  (This will typically be
  632. the transmit sequence of the corrupt frame, but that may not be the
  633. case if other frames were lost.)
  634.  
  635. III.5  Channel Access Procedures
  636.  
  637. Packet radio does not exactly resemble any wireline medium. 
  638. Different packet radio configurations, in turn, have different
  639. physical characteristics which impact procedures.
  640.  
  641. The purpose of the channel access procedures is to guarantee that a
  642. shared channel does not reach a state where additional demand causes
  643. net throughput to decrease precipitously, a condition known as
  644. congestion collapse.  This has been a significant problem in AX.25
  645. networks.  It is essentially impossible, however, in properly
  646. operated Ethernet networks.
  647.  
  648. III.5.1  CSMA operation
  649.  
  650. If it were not for the "hidden transmitter" problem, packet radio
  651. half-duplex operation would resemble carrier sense multiple access
  652. operation.  CSMA operation can, however, be achieved when half-
  653. duplex packet stations operate through a repeater (a two-frequency
  654. repeater, not a digipeater).  The repeater regenerates everyone's
  655. transmitted bits so that everyone else can hear them; this prevents
  656. any station from transmitting on top of another station unless they
  657. both start transmitting at almost exactly the same time.
  658.  
  659. In CSMA operation, an A802 station with data to transmit first waits
  660. until the channel is free.  It then waits for a random period of
  661. time t in the range m < t < s, where s is the slot time.  Slot time
  662. is represented by TXdelay + Df:  The sum of the transmitter keyup
  663. delay (TXdelay in some packet radio TNC operation) added to a
  664. constant Df.  (Ideally, in a system where TXdelay is not long, Df
  665. represents the duration of a minimum-length frame; initially here,
  666. it should be at least equal to TXdelay, so that slot time is at
  667. least twice TXdelay.  This value requries further study.) The
  668. minimum wait, m, is equal to TXdelay.
  669.  
  670. On retransmissions, however, slot time increase exponentially:
  671. TXdelay  + (Df*(2^t)), where t is the retransmission number
  672. beginning with 0 (for the first transmission) and ending with r. 
  673. Thus each retransmission delay will take, on average, almost twice
  674. as long as the previous delay.  But this is only the outer bound of
  675. a random function.
  676.  
  677. III.5.2  CSMA/CD operation
  678.  
  679. IEEE 802.3 and Ethernet use a contention technique called carrier
  680. sense multiple access / collision detection, or CSMA/CD.  This is
  681. based on the concept that every transmitting station is
  682. simultaneously listening, so it knows if its signal was "clobbered"
  683. -- it compares the received signal to the transmitted one.  
  684. (Ethernet, keeping it simple, uses a current source into a fixed 50
  685. ohm load.  If the voltage goes above the transmitter's own output
  686. voltage -- i.e., it detects 6 v when it transmits at 3 v -- then it
  687. knows a collision has occurred.  This obviously does not work when
  688. an antenna is used.) 
  689.  
  690. Stations must listen before they transmit.  However, it is possible
  691. that two stations choose to transmit at almost exactly the same
  692. time.  This causes a collision.  Since the station is listening,
  693. though, it does not complete sending the packet.  It stops
  694. transmitting and waits a random interval within (2^n * slot_time),
  695. where n is the retransmission count.  
  696.  
  697. This leads to a conclusion that, given sufficient received signal
  698. strengths (i.e., low bit error rate exclusive of collision), LLC-U
  699. operation is appropriate for CSMA/CD operation, while LLC-C
  700. operation is most desirable for CSMA operation.  If CSMA operation
  701. is used, then a collision-caused error can only be recovered by an
  702. end-to-end layer, either operating across a digipeater chain or at a
  703. higher layer.
  704.  
  705. From a practical perspective, CSMA/CD operation requires all
  706. stations to operate using full-duplex radios, listening to a
  707. repeater output even as they transmit to the input.  Hence very
  708. little amateur packet radio operation is true CSMA/CD.
  709.  
  710. III.5.3  Single-frequency operation
  711.  
  712. With a single frequency and no repeater, even true CSMA is not
  713. possible.  Stations must still listen before transmitting, but the
  714. sender might not hear a third station that blocks its transmission
  715. from reaching the receiver.  This is the "hidden transmitter"
  716. problem.  Single-frequency operation thus has a lower maximum
  717. channel throughput than true CSMA operation, though higher than
  718. Aloha operation, in which stations transmit without listening.
  719.  
  720. The same procedures as used in CSMA operation should be used in
  721. single-frequency operation.  However, it may be necessary to use
  722. longer initial slot times.  This is for further study.
  723. 
  724.